Day 4 - 用 Claude Code 分析一張競品截圖

看到競品首頁有一張醒目的卡片，團隊很容易立刻說：「我們也做一張。」但一張截圖能證明的是畫面上有什麼，不能證明設計原因、轉換效果或後端規則。今天練習把觀察與推論分開。

截圖分析的三層證據

第一層是可觀察事實：文字、按鈕、位置、層級、狀態。第二層是互動推論：某元素可能引導哪個行動。第三層是產品假設：團隊可能希望改變什麼行為。

這個分層借用 GOV.UK 研究分析流程先擷取觀察、再整理發現、最後決定行動的原則；單張截圖比使用者研究資料更有限，因此推論需要更保守。

例如畫面上方有「建立第一個任務」按鈕，事實只有按鈕文案與位置。它「可能是主行動」是推論；「產品希望新成員快速建立任務以提高留存」則跨到商業假設，截圖本身無法確認。

常見失誤包括：把視覺醒目直接當成成效好；把登入前行銷頁當成登入後產品流程；忽略角色、方案、裝置與個人化條件；讓 AI 憑產品名稱補出截圖外的功能。

準備一張可以負責的截圖

FlowBoard 是虛構產品，因此今天請讀者自行選一個可合法查看的公開競品頁面，或使用自己帳號中的產品畫面。選擇與「新成員加入後不知道下一步」相近的首頁、空白狀態或首次使用頁面。

保存原圖，不裁掉瀏覽器時間與頁面脈絡，另記錄：

來源：產品官方網站／官方說明中心／自有帳號
網址：
查閱日期：2026-09-15
登入狀態：登入前／登入後
已知角色與方案：
裝置與視窗：
看不到或無法確認的資訊：

若公開頁面沒有穩定截圖，就自行截取你有權查看的畫面。

截圖前先完成一次目標任務，記下你從哪一頁抵達、點擊之前發生什麼、截圖之後預期去哪裡。單張圖仍是今天的分析單位，但前後脈絡會幫助你辨認哪些是已知、哪些只是猜測。若畫面含客戶名稱、成員頭像或任務內容，先遮蔽可辨識資訊，再交給核准的 AI 工具。

先人工抄錄，再交給 AI

以一張教學用模擬畫面為例：

• 左側是專案導覽列
• 主區標題為「歡迎加入設計改版」
• 下方有三張卡片，分別是「查看分派給我的任務」「認識專案」「完成個人資料」
• 第一張卡片使用實心按鈕，其餘為文字連結。
  （這是模擬畫面描述，不是任何真實產品）

(此截圖放在路徑 images/competitor/home.png）

先建立觀察表：

接著才讓 AI 分析：

背景：
我們研究專案協作產品的新成員首次進入工作區體驗。

任務：
1. 逐項整理畫面元素，不遺漏可讀文字。
2. 判斷可能的主行動，列出視覺依據。
3. 對每個元素提出最多一項產品假設。
4. 列出僅靠截圖無法確認的問題。

輸入：
【附上截圖】
【附上來源紀錄與人工觀察表】

限制：
- 不使用截圖外的產品知識。
- 不推斷成效、使用率、商業模式或後端規則。
- 看不清楚時寫「無法辨識」，不得補字。
- 每項推論須引用元素編號。

輸出：
表格欄位：元素編號、觀察、互動推論、產品假設、信心（高／中／低）、替代解釋、待驗證方式。

範例輸出

這個輸出沒有說「競品證明查看任務最好」。它只產生一個值得驗證的方向。

從畫面回到 FlowBoard

把觀察轉成 FlowBoard 的研究問題，而不是功能清單：新成員是否已有被指派任務？若有，直接帶他查看任務是否比建立任務更符合角色？若沒有任務，空白狀態該由誰提供下一步？

這些問題會提醒我們：同一個「新成員」可能包含受邀執行者、專案管理者與旁觀者。截圖不能回答分群，但能暴露該補的脈絡。

若模型具備看圖能力，仍建議同時附人工觀察表。它可以作為比對基準，也讓純文字工具與團隊成員參與審查。當模型讀到的按鈕文字與人工抄錄不同時，先回到原圖確認，不要選擇較符合預期的版本。

人類需要檢查什麼

確認 AI 是否真的引用畫面元素；是否把「可能」寫成確定；是否忽略截圖外的狀態；是否因既有品牌印象加入未見功能。最好由第二人只看原圖複核觀察表，因為後續推論再精彩，也救不了錯誤抄錄。

今天的產出物

今天完成的是截圖分析 Prompt與一張「觀察／推論／假設」表。請保存原圖、來源及查閱日期。

明天會把單張畫面的元素整理成「功能、流程、假設」。Day 4 的元素編號將成為每一列分析的證據，不讓功能表靠想像擴張。

在 Claude Code 建立截圖觀察 Skill

今天建立的 Skill 只負責觀察，不負責猜測截圖外的產品規則：

mkdir -p .claude/skills/competitor-screenshot

---
name: competitor-screenshot
description: 分析競品產品截圖，區分可見事實、互動推論與產品假設。當使用者提供 UI 截圖要求分析時使用。
---

讀取使用者提供的截圖後，依序輸出：
1. 可直接看見的文字、元件、位置與狀態
2. 可能的互動推論，標記為推論
3. 需要額外資料才能確認的產品假設
不要描述截圖中看不到的頁面、成效或後端規則。

把合法取得的圖片放進專案，我們用上面的模擬競品圖，路徑 images/competitor/home.png，然後在 Claude Code 中輸入：

/competitor-screenshot 請分析 images/competitor/home.png

若 Skill 沒有讀到圖片，先確認檔案路徑，再把路徑和任務一起提供；不要叫 Claude 憑產品名稱補畫面。

執行後可以看到輸出被切成三段：可直接看見的事實、標記為推論的互動判斷，以及需要額外資料才能確認的產品假設：

這張圖同時保留了檔案路徑、指令與輸出，是今天最重要的實作證據。注意最後那段「需額外資料才能確認」，它就是用來擋住「畫面醒目所以有效」這類跳躍。

參考資料

• GOV.UK Service Manual：Analyse a research session
• GOV.UK Service Manual：Managing user research data and participant privacy